Once software has been released for general availability, software bugs are often discovered which were not detected during prior testing. New or updated files that contain fixes to the software bugs, also known as hotfixes, may later be made available to replace some existing files containing the software bugs. Additionally, an existing software feature may be modified subsequent to release, or a new feature may be made available for release. Again, new or updated files that contain the modifications or the new feature may be made available to replace some existing files. These updates to software have traditionally been made by packaging a single copy of each file that needs to be updated on a system. This approach to updating software assumes customary linear file versioning for a single source code base into which file changes are made incrementally.
However, updating software using the approach for customary linear file versioning may fail for a software code base that is subsequently developed in parallel on two or more source code branches. A problem may arise whenever a file that needs to be updated has changed in a way that is incompatible with prior versions due to an intermediate change of that file taken from another source branch. For example, a file named foo.dll may be changed in a service pack that adds a new feature to the software. A new file named bar.dll that is dependent on foo.dll may also be included in the service pack for providing the new feature. This service pack may be applied to update the software on a target machine by replacing foo.dll and adding bar.dll on the target machine with the respective files provided from the source code branch for the service pack. The file foo.dll may also be changed in another source code branch for a hotfix package that corrects a software bug. The hotfix package may then be subsequently applied to update the software on the target machine by replacing foo.dll on the target machine with the file provided from the other source code branch. This may render foo.dll, upon which bar.dll depends, incompatible with the service pack software version. Updating such a file requires a change that is compatible with the prior service pack version and the newer hotfix package version of the file.
Another problem may arise whenever all the files on the system are updated at the same time such as during the intermediate change discussed above. In this case, any previously applied update may be lost. Returning to the example above, the file foo.dll that is replaced by the service pack update may have contained an earlier hotfix for a software bug that was made on yet another source code branch and loaded on the same target machine prior to loading the service pack. The changes that are compatible with the earlier version of the file need to be reapplied to the target machine.
A third problem may arise if the intermediate change is to be completely removed from the target machine. Typically, an uninstall program is used to remove any service pack or hotfix package. In the case of the example discussed above, the intermediate change may not be removed completely if the changes compatible with the earlier version of the file are reapplied to the target machine because the uninstall program will usually remove a file only if it is the version of the file that it installed. The changes compatible with the earlier version of the file, if reapplied, will therefore not be removed, and the file will be incompatible with files on the system after un-installation.
What is needed is a way for updating either selected files or all files of a target machine for updates made in a software code base developed in parallel on one or more branches. Additionally, such a system should allow previously loaded changes to be reapplied to the target machine and subsequent changes to be uninstalled so that the files are compatible after un-installation.